This chapter describes how to use the Differentiated Services (DiffServ) feature so that a router can provide preferred service to appropriate IP data packets. Based on information in the IP header, the router classifies packets by matching them with predefined configurations in the policy database (created with the policy feature). See "Using the Policy Feature" for details. As a result, some packets may receive preferred service. This chapter consists of the following sections:
Most forwarding devices installed in an IP network today deliver standard best-effort service to data packets on a first-come, first-served basis. This delivery method is adequate for most traffic, but new applications are emerging that require faster and earlier transmission of certain packets.
The Differentiated Services (DiffServ) feature provides different levels of service to IP packets when a router processes them for transmission. DiffServ provides some packets with preferred service by reserving system resources (buffers) and link resources (bandwidth) for them. A DiffServ classifier function determines the type of service given to IP packets by examining various fields in the IP header, for example, ranges of IP source and destination addresses and port numbers, protocol type, and incoming DS (TOS) byte. To accomplish this in a scalable way, individual flows are aggregated into streams. Streams are the entities through which DiffServ manages access to buffers and bandwidth. Figure 28 shows how DiffServ processes the packets of a stream.
Figure 28. DiffServ Data Packet Path
|
In addition to the traditional best-effort service, DiffServ provides the following types of service:
AF traffic is optionally metered and policed by means of the configuration in the policy. The supported policing types are single-rate and two-rate Three Color Marker (TCM). TCM enables packets to be classified or re-marked based on characteristics of the incoming traffic. Three classifications are provided: Green, Yellow, and Red. The policy provides for the specifying of thresholds for the color classification. The AF/BE queue provides AF service and is shown in Figure 29.
Local routers create and send control packets, so you must also leave enough resources free so that they receive adequate service.
DiffServ metering, marking, and policing in an edge router enables the core router in DiffServ-enabled networks to classify packets based on DS (TOS) codepoint and control congestion by dropping non-conforming traffic or decreasing its service level. For example, the core router may discard all red packets, forward yellow packets as best effort, and forward green packet with a low drop probability. This helps to achieve increased throughput and lower delay for preferred traffic in DiffServ-enabled networks.
DiffServ is currently implemented on PPP, Multilink PPP, and Frame Relay links, and can be used by the RSVP subsystem. Figure 28 shows how packets of a stream are processed. When a router receives the first packet of a flow (assuming that it is designated for premium service), no indication of its service category exists in the DiffServ cache, so the packet is processed by the slow path. DiffServ invokes a search of the policy database to obtain the packet-handling criteria (policy). The policy-defined action is saved in the DiffServ cache. When the router receives a subsequent packet of this flow, it finds that an entry in the DiffServ cache for the flow already exists, so its policy-defined action is applied and the packet takes the fast path. Thus, subsequent packets from this flow receive premium service.
Figure 29 shows the relationship between the policer, buffer management, the queues, and the scheduler--some of the basic components that provide different quality of service levels.
Figure 29. Relationship of Policer, Buffers, Queues, and Scheduler
 |
The expedited forwarding (EF) and assured forwarding (AF) services have different characteristics, which are supported by three functions in the router: (1) The meter and policer, (2) buffer and queue management, and (3) the scheduler. These functions provide more sophisticated traffic control than is available in a traditional BE router device.
Once you have used the policy feature to configure appropriate policies, the first step in implementing DiffServ is to use the DiffServ enable ds command to enable the DiffServ feature, and the set interface command to enable the egress interface.
It is possible to configure DiffServ options such that the network resources are overcommitted or overbooked, that is, the traffic conditioner controls are configured as though there were more bandwidth or buffering than is actually available. DiffServ does not support overbooking.
If a DiffServ stream becomes idle (no packets have been sent on the stream for some time), the system reclaims the resources so other streams can use them. If the stream reactivates, the resources are returned to it. If the resources are no longer available because of overbooking, then DiffServ periodically attempts to reallocate the resources.
DiffServ provides a replacement header for the IPv4 TOS octet as defined in RFC791, which contains a byte called the Diffserv (DS) field (shown in Figure 30. The six high order bits of the DS field are used as a DiffServ codepoint (DSCP) to determine the per-hop-behavior (PHB). The remaining two bits are reserved for future use. The following example shows the format of the DS field:
Figure 30. DiffServ Codepoint Format for IPv4 TOS Octet Header
 |
The recommended codepoint for the EF PHB is 101110xx.
Figure 31 shows the format of the DS field for the AF PHB:
Figure 31. DiffServ Codepoint Format for AF PHB Header
 |
The following list shows the recommended AF codepoint values with AF
classes and drop precedence values:
| Class 1 | Class 2 | Class 3 | Class 4 |
| AF11 = 001010xx | AF21 = 010010xx | AF31 = 011010xx | AF41 = 100010xx |
| AF12 = 001100xx | AF22 = 010100xx | AF32 = 011100xx | AF42 = 100100xx |
| AF13 = 001110xx | AF23 = 010110xx | AF33 = 011110xx | AF43 = 100110xx |
Metering and policing is provided for EF and AF traffic as specified in policy. The EF algorithm meters the traffic and drops packets that are over the specified threshold. The AF algorithm meters the traffic and possibly re-marks packets, but does not drop.
EF traffic has a default, token bucket-based policer, which drops packets if they exceed the rate specified during policy bandwidth parameter setup. You may specify the Token Rate (TR) and Token Bucket Size (TBS) parameters to change the policer default operation. The meter determines whether the bucket contains a sufficient number of tokens to send a packet. If tokens are available, the packet is sent. If not, the policer drops the packet. The bucket replenishes tokens at the rate specified in the Token Rate parameter. The token rate is measured in bytes per second, that is, it includes the IP header, but not link-specific headers. The token rate is measured before the IP header compression and Layer 2 data encryption and compression. Token Bucket Size is used to handle temporary bursts over the rate limit without penalty.
AF traffic has three policing options: (1) single-rate Three Color Marker (srTCM), (2) two-rate Three Color Marker (trTCM), and (3) none (no policing). These policing options are available for AF1, AF2, AF3 and AF4 classes and are specified during policy setup.
The srTCM meters a traffic stream based on a token bucket algorithm with two buckets and a single replenishment rate. It marks its packets as either green, yellow, or red according to three traffic parameters: (1) Committed Information Rate (CIR), (2) Committed Burst Size (CBS), and (3) Excess Burst Size (EBS). A packet is marked green if it does not exceed the CBS, yellow if it does exceed the CBS but not the EBS, and red otherwise. The CIR is measured in bytes of IP packets per second, that is, it includes the IP header, but not link-specific headers. The CIR is measured before the IP header compression and Layer 2 data encryption and compression. The CBS and the EBS are measured in bytes.
The meter operates in either color-blind or color-aware mode. In color-blind mode, an incoming packet is assumed to be marked green, regardless of the setting of the drop precedence bits in its DS codepoint. CBS represents the size of the green bucket, and EBS represents the size of the yellow bucket. First, the green bucket is checked for available tokens. If there are enough green tokens, then the packet is marked as green and sent. If there are not enough green tokens, then the yellow bucket is checked. If there are enough yellow tokens, then the packet is marked as yellow and sent. If there are not enough yellow tokens, then the packet is marked as red. In color-aware mode, the color of the incoming packet is checked and the corresponding token bucket is checked first. If tokens are available it is sent as received. If not, its drop precedence value is reduced appropriately. Color-aware mode is useful if ingress packets are already classified and pre-color marked.
The trTCM is also a token bucket algorithm, similar to srTCM, except that it provides separate replenishment rates for the green and yellow buckets. The configuration parameters are: (1) Committed Information Rate (CIR), (2) Committed Burst Size (CBS), (3) Peak Information Rate (PIR), and (4) Peak Burst Size (PBS). CBS represents the size of the green bucket, and PBS represents the size of the yellow bucket. The algorithm is the same as for srTCM, except that the CIR value determines the green bucket replenishment rate and the PIR value determines the yellow bucket replenishment rate. The trTCM is useful if a peak rate needs to be enforced separately from a committed information rate. The packets that exceed the PIR will be marked red (highest drop probability).
If traffic is for EF, or is AF or BE traffic that the policer has allowed, the rate-based buffer management function processes it. This function allocates buffers from either a private pool or from a common shared pool for the DiffServ-enabled output interface. Buffers for EF traffic are allocated only from the private pool.
Use the Talk 6 set receive-buffers configuration command (see Software User's Guide for a description and the syntax) to specify the total amount of physical buffer space available to an interface. Use the DiffServ Talk 6 set interface command to set the egress buffer size for the premium and assured queues. This is the buffer space that DiffServ manages.
DiffServ manages two separate pools--one for the premium (EF) queue and one for the assured forwarding (AF) queue. Ensure that the buffer space you specify reflects the actual amount of buffer space available in the system.
Buffer management determines whether buffers from its interface's private pool are available for the packet. If there are, it accepts and enqueues the packet. If they are not, it attempts to allocate buffer space from the shared pool and if it can, it enqueues the packet. If no shared buffer space is available, buffer management drops the packet.
The scheduler function examines the queues on a regular basis, dequeues enqueued packets, and sends them to the interface adapter for transmission. It is a self-clocked fair-queuing scheduler, which is a variation of weighted fair queuing. You may configure the scheduler weights and specify the frequency at which the scheduler examines the queues.
The following terms are used when discussing DiffServ:
The following procedures provide a high-level description of how to configure DiffServ to provide preferred service for selected packets. First, access the DiffServ feature:
* talk 6 Config>feature ds DS config>
DS config>enable ds DiffServ enabled
DS config>set interface
Enter Diffserv Interface number [0]? 2
Set Premium Queue Bandwidth (%) (1 - 99) [20]?
Assured Queue Bandwidth (%) = 80
Configure Advanced setting (y/n)? [No]: no
Accept input (y/n)? [Yes]:
| Note: | If you specify no to the Configure Advanced setting prompt, then default parameters for Premium Queue and Assured/BE queue will be used. |
Configure Advanced setting (y/n)? [No]: yes
Set Premium Queue Weight (%) (20 - 99) [90]?
Assured Queue Weight (%) = 10
EGRESS BufSize for Premium Queue (in bytes) (550 - 27500) [5500]?
Max EGRESS QoS Allocation for Premium Queue (%) (1 - 99) [95]?
EGRESS BufSize for Assured/BE Queue (in bytes) (5500 - 140800) [27500]?
Max EGRESS QoS Allocation for Assured/BE Queue (%) (1 - 99) [80]?
In this example, 20 percent of line bandwidth, and 90 percent of scheduler weight are given to the EF queue. The egress buffer size for the EF queue is 5500 bytes (which is 10 packets with an average packet size of 550 bytes), out of which 95 percent is allocatable to QoS streams. The egress buffer size for the AF/BE queue is 27 500 bytes (which is 50 packets with an average packet size of 550 bytes), out of which 80 percent is allocatable to QoS streams.
After enabling DiffServ and setting interface parameters, you must restart or reload the device to activate DiffServ. For more details on specifying DiffServ commands, see "Configuring and Monitoring the Differentiated Services Feature".